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The Autonomous Flight Safety System (AFSS) being developed by NASA’s Goddard 
Space Flight Center’s Wallops Flight Facility and Kennedy Space Center has completed two 
successful developmental flights and is preparing for a third. AFSS has been demonstrated 
to be a viable architecture for implementation of a completely vehicle based system capable 
of protecting life and property in event of an errant vehicle by terminating the flight or 
initiating other actions. It is capable of replacing current human-in-the-loop systems or 
acting in parallel with them. AFSS is configured prior to flight in accordance with a specific 
rule set agreed upon by the range safety authority and the user to protect the public and 
assure mission success. This paper discusses the motivation for the project, describes the 
method of development, and presents an overview of the evolving architecture and the 
current status. 


I. Introduction 

W hen a space launch vehicle flies errantly, the ultimate action available to those responsible for the protection 
of property and public safety is quick and certain termination of the flight. Since the beginning of space 
flight this has been accomplished by tracking the vehicle with precision radars, returning the signals to computers at 
a control center, monitoring its progress and, if necessary, using high powered transmitters to send a command to 
on-board receivers. A 0.999 reliability specification requires highly reliable redundant systems. Since these 
systems rely on line-of-sight radio frequency transmissions, as the vehicle flies down range additional coverage by 
redundant radar and command transmitters is required. These systems must all be tied together by secure, reliable 
data communication networks. Maintaining and operating these systems, often at isolated locations, has become a 
major expense to launch ranges and their customers. 

The average range cost for each Atlas or Delta launch attempt is on the order of $500,000. In addition, pre- 
launch tests of the Flight Termination System (FTS) cost $100,000 and tests of the C-band radar tracking 
transponder and S-band vehicle telemetry system cost another $100,000 [1], 

Mobile Range assets such as the one operated by NASA’s Wallops Flight Facility or the Florida Air National 
Guard’s Ballistic Missile Range Safety and Telemetry (BMRST) systems can be pressed into service for trajectories 
visible to land areas when politically and programmatically available. The small fleet of deployable assets onboard 
ships and aircraft such as the Advanced Range Instrumentation Aircraft (ARIA), and the Airborne Instrumentation 
System (AIS) are being withdrawn from operations due to high costs of operation and maintainability. Neither of 
these systems addresses the needs of responsive space launch operations. Indeed, scheduling downrange assets for 
launch and testing prior to launch can be vexing even for permanent installations. 

When the expense and complexity can be borne, other serious issues with conventional flight termination 
systems must be considered. There are, for instance, launch situations in which hazards exist at the launch site that 
make the lag time inherent to human reaction a critical factor. FTS radio links have historically operated on 
protected frequencies within the 400-420 MHz frequency band. In the early 1990’s the National 
Telecommunications and Information Administration (NTIA) directed 400-420 MHz frequency band users to 
convert to narrow band or move to another frequency. Due to high Doppler requirements narrowband is not feasible 
for FTS. The Department of Defense (DoD) was directed by NTIA to discontinue use of 416.5 MHz, a traditional 
frequency without interference issues, and move to 420-430 MHz which is under military control but includes high 
power radar frequencies. These radars have been observed to cause temporary inability to send termination 
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commands to flying vehicles if it had been necessary to do so. Recent efforts concerning transition to the encrypted 
Enhanced Flight Termination System (EFTS) would prevent termination commands from being maliciously or 
errantly sent to a vehicle during nominal flight but would not overcome radio frequency interference risks [2], 

Flypersonic flight poses particular difficulties for traditional tracking and termination systems. Whether 
performed for weapons testing or scientific investigation, hypersonic research often requires long periods of flight at 
low altitudes, usually over open-ocean. Temporary placement of three to five tracking stations may be required to 
maintain line of sight communication with the flight vehicle. 

II. Autonomous Flight Termination As A Solution 

As noted previously, the basic approach to flight termination has changed little over the past half century. 
Meanwhile, technologies have matured which enable an entirely new alternative to the expense and complexity of 
the present system. 

The Global Positioning System (GPS) enables very accurate tracking information. GPS has been used to track 
launch vehicles since 1996 and is increasingly being used with or in lieu of radar [3]. Although acceptable by the 
Range Commanders Council (RCC) as a range safety tracking source, GPS has a potential weakness in that it has 
susceptibility to radio frequency noise, blockage, jamming and signal reduction caused by plume and ionization. A 
technique frequently used to mitigate this is coupling it with an Inertial Navigation System (INS), another 
technology that has undergone considerable improvement in recent decades. GPS and INS are complimentary in 
that each has a strength in the area the other has a weakness. Inertial measuring devices are immune to radio 
frequency problems and capable of very high output rates, but if unaided, are subject to drift over time. GPS is used 
to correct for drift. An integrated system is capable of supplying highly accurate time, position, and velocity 
information at a high rate. 

A third technological development unforeseen to inventors of the traditional ground based flight termination 
systems is the advent of computers with sufficient memory to handle a set of mission rules which may change based 
on position and previous flight events. Computers now have computational speed to ingest information from 
onboard sensors, predict impact points, and evaluate the information with respect to those rules within allowable 
times to ensure safe actions are taken. 

AFSS can take vehicle navigation data from redundant onboard sensors and make flight termination decisions 
using software-based rules implemented on redundant flight processors. By basing these decisions on actual 
Instantaneous Impact Predictions and by providing for an arbitrary number of mission rules, it is the contention of 
the AFSS development team that the decision making process used by Missile Flight Control Officers (MFCO) can 
be replicated in software. 

Although a truly autonomous system has no requirement for telemetry or command, these features may be 
incorporated, even in the absence of ground based systems through satellite transmission links. This would allow 
the position and dynamic conditions at the vehicle to be known at a time when termination actions were or were not 
taken. 

Autonomous systems must meet the same stringent requirements of any flight termination system. These 
requirements are tailored by individual ranges, but are generally specified in the RCC 319-07 Flight Termination 
Systems Commonality Standard. With cooperation of the AFSS development team and the national range safety 
leadership, the RCC 319 has been recently amended to add specific references to requirements for autonomous 
systems. Rules for GPS and INS are found in RCC 324-01 Global Positioning and Inertial Measurements Range 
Safety’ Tracking Systems’ Commonality Standard. The basic requirements include specifications for accuracy, 
timeliness of data, reliability and independence. 

A few, very simple. Autonomous Flight Termination Systems have been demonstrated. Certain Russian launch 
vehicles, including those launched by SeaLaunch, and the Isreali Arrow are capable of self termination based on 
simple parameter measurements such as pitch and yaw and violation of preset azimuth limits. Neither of these is 
deemed sufficient to protect life and property except for over very remote ocean areas or provide the level of 
mission assurance required of today’s civilian and DoD missions [4]. 
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TIT. NASA’s Autonomous Flight Safety System 



The National Aeronautics and Space Administration (NASA) has maintained a multi-center engineering 
development team for the Autonomous Flight Safety System since 2002 in an attempt to realize the benefits that 
such a system could bring to its launch operations. Such benefits include increases in public safety for mission 
profiles that include phases of propulsive flight that cannot be covered or are prohibitively expensive to cover with 
conventional ground based telemetry and command systems. Increases in safety are also realized for missions with 
phases demanding flight termination response times too quick for a conventional ground-based human in the loop 
system. 

The NASA AFSS development team has worked with the Range Safety community through the Range 
Commanders Council Range Safety Group (RSG) and Flight Termination Systems Subcommittee (FTSC) to 
formulate systems level functional, design, test, and maintenance requirements specific to the autonomous aspects of 
the system. The team has established an architectural design and concept of operations that achieves compliance to 
the fundamental requirements established by the Range Safety community. Ground and flight test prototype units 
have been built and tested to demonstrate the 
various aspects of the AFSS architectural 
design and concept of operations, also 
addressing feasibility in various high 
development risk areas. 

NASA’s AFSS architecture design permits 
flexibility to adapt to a variety of platforms. 

While a single processor with GPS inputs 
might suffice for a UAV, or a dual processor 
with GPS for a spinning sounding rocket, GPS 
and IMU inputs with three or more processors 
might be recommended for a large orbital 
launch vehicle. Thus, the system architecture 
supports inputs from an arbitrary number of 
navigation sensors and up to four flight 
processors housed in two physically separated 
chassis. Redundancy management of the Figure 1. NASA's Autonomous Flight Safety System 
navigation sensors is accomplished within a 

software module running on each of the flight processors. Redundancy management of the flight processor output 
functions is accomplished using redundant Field Programmable Gate Array (FPGA) based custom voting circuits. 
The flight software supports an arbitrary number of mission rules established by Range Safety Authorities using an 
inventory of rule types taken from current human-in-the-loop operational flight safety practices. The rules 
themselves are specified in a user configurable human-readable file, and are loaded into the AFSS application prior 
to flight. 

AFSS will be capable of operating as a stand- alone termination system. It will also be hand-over capable in that 
control could be transferred to or from traditional systems eliminating the need for downrange tracking assets. 
Alternatively it could be operated as a backup to conventional human-in-the-loop requiring only a single string of 
ground based radars and command systems. 


AFSS primary features are: [5] 

Redundancy. The design tolerates no single point of failure that would at any time inhibit the Range Safety 
functionality of the system. 

Complete functional independence from the launch vehicle. While connections between AFSS and the launch 
vehicle may be allowed for non-mission critical functions, or to enhance system redundancy for functions not 
directly related to flight termination assessments, the AFSS is a stand alone system 

Achieve a reliability of 99.9% with a 95% confidence level. 

Single point tolerance with regard to performance degradation during flight and inadvertent initiation of the 
termination command. 
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Flexibility to be customized to respect mission specific requirements from Range Safety organizations. 

Built in capability to issue telemetry throughout all mission phases by land based connections or by interfacing 
with a apace based telemetry system (e.g. TDRSS use by implementing the Low Cost TDRSS Transceiver 
II.CT2U 

Accommodation of mission assurance goals through provision of green-time computations, avoidance of “quick 
trigger” or single data point decisions, redundant sensors and other techniques. 

IV. Architecture 

An endeavor of small, responsive teams at two NASA centers, with limited and at times, sporadic finding, AFSS 
has been developed spirally. The team includes Range Safety specialists from DoD’s Eastern Range and NASA’s 
Wallops Flight Facility, the Wallops Range Chief Engineer, and engineers with many years of experience designing, 
building and supporting rocket flight instrumentation. The approach agreed upon was to focus resources on items 
that pose high development risk and potential feasibility issues and address those items on engineering breadboard 
and flight prototype units. A system architecture was developed that allows delay of certain design decision 
commitments (e.g. subsystem redundancy requirements) until deployment on a specific vehicle from a particular 
range. The stated goal was to develop proof of concept systems advancing toward a flight prototype. 

Experienced flight safety experts including MFCOs, formulated systems level functional, design, test, and 
maintenance requirements focused on the autonomous aspects of the system. Requirements, approaches to meet the 
requirements, and tradeoff decisions were regularly briefed to the Range Commanders Council Range Safety Group 
and its Flight Termination Subcommittee to secure their advice and concurrence. Continuous communication has 
been maintained with this group, multiple launch ranges and numerous potential users. Many topics uncovered and 
discussed during these exchanges were later codified into the new release of the RCC 319 document. 

In accordance with the level of funding, Commercial off the Shelf (COTS) hardware has been used as much as 
possible. The goal of the hardware development effort has been to build a flight “qualifiable” rather than a flight 
qualified system. All components have been designed, selected, or modified to support functional requirements 
such as redundancy, computational speed, and latency. All are considered capable of meeting rigorous 
environmental specifications but were only tested to flight qualification levels for vehicles on which they were 
flown. Meeting component qualification levels was considered outside the scope of the project or delayed until later 
in the project to ensure maximum return on the limited funding available. Resources have not been available to 
optimize the size or weight of the unit. For demonstration purposes, some requirements deemed expensive, yet not 
technically challenging such as qualification of flight batteries, has been purposely delayed into the future. A total 
of four test flights are planned. Each is to exhibit further maturation of the design. Two have been completed. 
Another is scheduled for Fall 2008. 

Figure 2 shows the AFSS functional baseline and highlights its subsystems. 
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Figure 2. AFSS Block Diagram 


AFSS supports interfaces to multiple navigation sensors types. Each sensor providing state vector data must be 
sampled at a rate that meets Range Safety requirements. The sensor must maintain lock and accuracy through 
dynamic maneuvers such as acceleration and tumbling. Every sensor must be qualified through environmental 
testing relative to the mission to be flown. 

Global Positioning System (GPS) systems and Inertial Measurement Units (IMU) will be the type of sensors 
used by the AFSS to gather navigation data. Any sensor used in the system must interface with all the preprocessors 
used in order to provide redundancy. The navigation sensors can be located inside or outside the chassis, and can be 
powered by the chassis or receive power directly from independent power supplies. In order to use a GPS system, 
the AFSS will allocate both an antenna and a receiver unit. Where dual GPS tracking systems are used as the only 
source of tracking, each GPS unit should utilize a set of antennas positioned with an optimal radial offset from each 
other. 

Data from each sensor will be validated prior to being used in the AFSS algorithm. Different techniques are used 
for the single sensor data validation: 

•S Validate the sensor data message checksum 

V Prescreen with any self-monitoring status indicators included within the sensor data message. 

V Perform reality checks on the sensor using data derived from the navigation message. 

V Verify that the sensor data latency is within the allowed range. 

V Perform sensor validation tests using user configurable rules 

In addition, a sensor cross validation algorithm will be used to ensure individually validated navigation sensors 
are grouped within an acceptable error tolerance. The algorithm is structured to determine which sensors produce 
navigation solutions outside of the ‘main grouping’ of sensors and to flag those as invalid. 

Multiple flight processor units are individually interfaced with every sensor and a Command Switch Logic and 
Interlock Circuit (CSLIC) unit. Each unit provides the means for power and data interfacing between all the AFSS 
components. 

Current limiting is provided to prevent damage to the Power Supply Unit due to overload or short circuit 
conditions, and the recovery occurs automatically on removal of the fault condition. In addition, over- and under- 
voltage protection is provided on each regulated output line. Interfaces are provided for monitoring the processors 
prior to launch and allow loading of necessary flight application software, flight rules, or configuration files. 

An interfacing board carries commands from the processor to the CSLIC units. There are different types of 
commands that can be relayed: 
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V Flight Processor Enable - Thid function is used to tell the CSLIC how many flight processors to expect for 
a given mission. 

V Flight Processor Monitor - The Monitor (MON) line is used to communicate health status of the Flight 
Processor (FP) to the CSLIC. The MON line goes through a set of relay-like devices such as Opto- 
Isolators, Mechanical, Solid State or Programmable Logic Controllers and command them open or closed. 

■S Ready-To-Launch (RTL) - The RTL line is set high on each FP as part of the normal launch countdown 
process. RTL logic is independently evaluated on each FP to permit manual or automatic launch aborts. 

■S ARM and FIRE - A two-step action is implemented to initiate a destruct action on each FP. Upon 
experiencing a flight constraint violation, the FP will set the ARM line high, followed by the FIRE line. 

A. Command Switch Logic and Interlock Circuit (CSLIC) 

The flight processors independently cross-check and validate all of the navigation sensors, update various 
internal state variables, and output discrete ARM/FIRE/RE AD Y-TO-LAUNCH functions in accordance with a set 
of mission rules loaded prior to launch. The outputs from all of the flight processors drive redundant ordnance 
initiation paths through the use of two CSLIC devices. 

Each CSLIC card is based on a Field Programmable Gate Array (FPGA) reconfigurable logic and uses 
Electrically Erasable Programmable Read-Only Memory (EEPROM) to support automatic loading of the FPGA 
upon application of power. 

The primary function of the CSLIC is to provide a simple, highly reliable interface between the outputs of the 
multiple independent flight processors and the flight termination system (FTS) ordnance train in a manner consistent 
with the Range Safety requirements for fault tolerance. A secondary function of the CSLIC is to provide an 
interface between the AFSS and the launch vehicle countdown process to permit an automatic launch abort if the 
AFSS or one of its subsystems experiences a fault prior to launch. 

While on the ground, the card can receive two input signals, i.e. MASTER-ARM and MASTER-SAFE from the 
Ground Support Equipment (GSE). As a consequence, it latches or unlatches an internal ENABLE inhibit in an 
ARMED or SAFE state. 

During flight, the card receives sets of FPE, MON, RTL, ARM, FIRE, logic signals coming from each single 
board computer, residing either in the same or in different chassis. After applying the required voting analysis, it 
provides four output signals, i.e. ENABLE-CMD, ARM-CMD, FIRE-CMD and RTL-CMD for driving the Flight 
Termination System. [6] 

B. Primary Power Supplies 

The AFSS and its components are powered by sources independent from the Lunch vehicle. A separate battery 
must power each processor unit and CSLIC pair. The nominal voltage to be provided is 28V, with 22V and 45V as 
accepted lower and upper limits. 


V. Software 

A variety of hardware options are viable for autonomous systems. As noted above, hardware has been a 
secondary focus of the development project. The algorithms that successfully define and evaluate the mission rules 
and the software that place them in effect is the essential, truly innovative portion of autonomous flight termination. 

When one contemplates the variety of mission rules and considerations in use by Range Safety organizations and 
the subtle differences in approach to similar missions, it becomes immediately apparent that in order for an AFSS to 
be useful, it must provide substantial flexibility in the area of mission configuration. In the algorithm organization 
of the AFSS, this flexibility is achieved by generalizing the concepts of ‘mission rules’, ‘mission data entities’ and 
‘mission modes’. 

A mission data entity is primarily a data storage construct referenced by a mission rule. In the realm of range 
operations, the mission data entity represents a physical flight corridor boundary, gate, or perhaps a time dependent 
parameter required to evaluate the status of a mission rule. Four basic entities are supported within the proposed 
framework; boundaries, gates (moving and stationary), data tables (e.g. green-time calculations), and vehicle stage 
specific data. 

A mission mode is an internal variable indicating status of an expected event. Examples of this include an AFSS 
ready-to-launch flag. Boolean variables indicating whether or not the current stage is thrusting, and an orbit flag. 
Mission mode variables may also be referenced by a mission rule in determining whether or not preconditions for 
the application of the rule have been met. 
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A mission rule is primarily used to trigger a destruct condition, but can also be utilized to affect user defined 
mission modes. Examples of mission rules linked to destruct include impact position/present position boundary 
limits, gate conditions, green-time limits, and generic mission parameter threshold limits. A rule can also be used to 
flag when a certain condition has become true (e.g. gate passage) without raising a destruct condition. This flag can 
then be utilized as a precondition for a rule tied to destruct. There are four classes of mission rules: 

a. The Parameter Threshold Rule allows the user to specify one or more threshold (or Boolean truth) 
conditions that will trigger a destruct condition. This type of rule is the most versatile. It can be used to 
implement mission rules for erratic flight, no pitch program, no stage ignition, and low performance. 

b. The Map Boundary Rule possesses support functions for evaluating whether or not a specified set of 
vehicle coordinates (present position or projected impact position) is inside or outside of a simple closed 
curve described in an associated boundary entity. 

c. The Gate Rule possesses support algorithms for evaluating whether or not a specified set of vehicle 
coordinates (present position or projected impact) has advanced beyond a line described in an associated 
gate entity. 

d. The Green-Time Rule possesses support functions for evaluating whether or not a flight containment rule 
could be violated during a period of time within which the AFSS software has received no valid navigation 
solution data. 

The flexibility of the proposed architecture results from the rich set of system modes and state variables made 
available to the various mission rules. Therefore, it is expected that this modest library of rule types will 
accommodate virtually any ELV mission. 

Configuration of these rules with respect to mission modes must not only assure flight termination when 
warranted, but support mission assurance. For instance, the System Arm/Destruct algorithms must not activate the 
System-Destmct mode based upon a single data point indicating a Destruct Condition. A lag time for the System- 
Arm and Destruct modes is mission configurable to filter out scenarios where a vehicle quickly passes into and then 
exits a Destruct Condition. For cases where the vehicle rides on the margin of a mission rule, repeatedly entering 
and exiting a Destruct Condition within the programmed lag time, it is not acceptable for an Arm/Destruct ‘timer’ to 
instantaneously reset upon each exit. 

Based upon these considerations, a user-configurable timer is used to affect the Arm and Destruct functions. A 
System-Destruct-Signal timer is maintained by the decision flow algorithms. When a Destruct Condition is 
indicated by one of the mission rules, the System-Destruct-Signal timer starts an upward count. When no Destruct 
Condition is indicated, the System-Destruct-Signal timer counts down. On the low end, the System-Destruct-Signal 
timer is clamped so that it will not count down below zero. On the high-end, it is clamped to limit the worst case 
time increment required to release the destruct function. 

System-Arm is activated when the System-Destruct-Signal timer exceeds the user specified Time-To-Arm 
threshold value, and System-Destmct mode is activated when the System-Destruct-Signal timer exceeds the user 
specified Time-To-Destmct threshold value. 

With this framework, it is recognized that the AFSS software implementation must accommodate the user 
configuration of an arbitrary number and variety of so called data entities and rules to support a mission. The AFSS 
software implementation must support the monitoring of modes for an arbitrary number of vehicle stages. The 
result is an efficient, stripped-down, rule-based system flexibly tailored to the range safety application required. 

VI. Four AFSS Test Articles 

Spiral development of AFSS is tied to four launch vehicle flights, not connected to vehicle ordnance, each 
demonstrating incremental progress of a test article (TA) toward a qualifiable system. Two of these flights have 
been successfully completed. Design is nearly complete for a third planned for Spring of 2009. 

A. TA1 

Test Article One (TA1) was flown on a two stage NASA Sounding Rocket from White Sands Missile Range on 
April 5, 2006. It consisted of a single chassis, dual processor unit with inputs from two GPS receivers. The primary 
purpose of this pathfinder flight was to demonstrate the key elements of the AFSS concept of operations pertaining 
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to pre-launch setup, bench testing, vehicle integration, in-vehicle end-to-end testing, countdown system verification 
procedures, and flight operations. 



Figure 3. Test Article 1 


Two commercial CA code GPS receivers provided navigation data: a Javad JNS100 GPS card mounted inside the 
AFSS enclosure and an Ashtech G12 GPS mounted in its own enclosure external to the AFSS enclosure. Both 
receivers used data from a skin-mounted wrap-around GPS antenna. The GPS receivers were programmed to 
provide updated three-dimensional position and velocity measurements at 1 0 Hz. Extended-temperature industrial- 
grade PC 104 form-factor components were mounted in a commercial Parvus avionics enclosure. There were two 
MPL MIP405 single-board computers, each with a PowerPC 400-MHz-series CPU. Each computer had Ethernet 
capability for Ground Support Equipment (GSE) input/output and four asynchronous serial ports for connections 
with the GSE, the GPS receivers, and the vehicle’s telemetry system. 

Two different sets of mission rules were developed for this test, one for each processor. The set for Processor #1 
(designated as the nominal processor) was configured so that a nominal flight would not result in any flight 
termination actions. The rule set for Processor #2 (designated as the errant processor) included three additional rules 
so that multiple destruct activations would occur during a nominal flight. 

The errant processor was to issue termination commands as it crossed a gate, again as it crossed an artificial 
protected “island” and again as it failed to detect third stage ignition of the two stage vehicle. The AFSS was not 
connected to a flight termination system and it could not initiate any destruct actions. Each processor interpreted its 
rule set correctly and the errant processor issued destruct commands on each of the three programmed violations. [7] 
The following rule sets were tested: 

■S Configurable time-to-arm and time-to-destruct 
•/ Pre-launch ARM/DESTRUCT function verification test 
•S Pre-launch loss of data detection and HOLD function 
■S Liftoff detection 
■S Stage ignition detection 

•S Instantaneous Impact Point computation and boundary violation (Range “Keep-In” Boundary) 

•S Errant flight detection (Flight Azimuth limits) 

K Green-time computation 

•S In-flight loss of data detection and Green-Time destruct 
K No stage destruct 

B. TA2 (Demo 2) 
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The second test article was flown aboard the Space Exploration Technology Incorporated (SpaceX) Falcon 1 
expendable launch vehicle from the Reagan Test Site on March 21, 2007. This effort was partially funded by the 
Defense Advanced Research Projects Agency (DARPA) under the DARPA/USAF Falcon Program to demonstrate 
Operationally Responsive Space (ORS) technologies. This test article contained redundant flight processors, a 
voting circuit, a power supply module, and a GPS receiver deployed in a flight qualifiable conduction cooled 
chassis. 

Also flown with the AFSS chassis was an externally mounted GPS receiver for navigation solution redundancy 
and a 10-Watt Low Cost TDRSS Transceiver (LCT2) developed by NASA’s Wallops Flight Facility to demonstrate 
space-based range ORS technologies also under the DARPA Falcon Program. Despite the previous successful 
completion of compatibility testing with launch vehicle systems, a concern was raised on launch day that LCT2 
could potentially interfere with the vehicle GPS. With insufficient time available to permit additional conclusive 
testing, a decision was made by the Falcon 1 launch management team, DARPA, and NASA to fly with the LCT2 
powered off. The data from one of the flight processors was re-routed through the vehicle telemetry system so all 
but a subset of the detailed data from the other was available for post-test analysis. 

This mission was a pathfinder exercise in which the AFSS engineering development team was able to apply 
many elements of the AFSS Concept of Operations within the integration, test and launch operations environment of 
an Expendable Launch Vehicle. 



LCT2 


Access Connectors 
TTB SpaceX Box 
GPS Splitter 



-GPS Switch 
Interface Connectors 


Radstone RT4 Chassis 
• 2 processors 
■ CSLIC 

■#1 JAVAD GPS 
- Power Supply 


Ethernet Box 
1 

*2 JAVAD GPS 


TDRSS Antenna 
Splitter 


Figure 4. TA2 Mounted on SpaceX 

As is widely known, the Falcon 1 vehicle did not achieve orbit. The AFSS however was able to meet its test 
objectives. These included successful operation and post-flight performance characterization of the AFSS hardware 
and software elements. Included in the mission rule set were flight termination rules established to replicate Range 
Safety Officer judgment. No pre-launch attempt was made to coordinate the rules programmed into the AFSS with 
those of the launch range. Independent rules allowed the AFSS team to construct a rule set which best tested the 
software. At most launch ranges, the Range Safety Operations Plan includes a mission rule that calls for termination 
of flight if the vehicle demonstrates “obvious erratic flight” where in the judgment of the Range Safety Officer, 
continued flight may pose unacceptable safety risk. Both processors issued ARM and FIRE functions associated 
with the anomalous vehicle performance experienced during flight. Using the available telemetry data, the team can 
confirm that the termination command was issued due to a violation of a moving-gate rule established to catch 
erratic flight from “in-plane” vehicle failures. [8] 
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Components of TA2 shown in Figure 4 include: 

> AFSS Chassis - Two Radstone IMP2A flight processors (designated FPO and FP1), a JNS100 GPS Receiver, 
and a custom FPGA based CSLIC mounted in a Radstone RT4 conductive cooled chassis. This item was the 
focus of the test. 

> LCT2 - A NASA/Wallops Low Cost TDRSS Transceiver was included in the test as the primary means of 
receiving data from the AFSS Chassis. Status data from both FPO and FP1 were routed through the LCT2 using 
a 19200-kbps TDRSS data link. Also included in this data link was the full rate (10-Hz) data from both GPS 
receivers. 

> GPS and Ethernet Boxes - In addition to the GPS receiver mounted within the AFSS Chassis, a JNS100 GPS 
receiver was packaged and mounted externally to the chassis in order to test the ability of the AFSS to negotiate 
navigation data from redundant sources. A DC blocker was used at the RF input to prevent the External GPS 
from powering the Low Noise Amplifier (LNA) integrated with the antenna. A COTS Ethernet switch was 
mounted in a box on this stack, providing facility for OS kernel, application, and configuration file uploading 
during testing and preflight operations. 

> Relay Box (SpaceX TTB) - A SpaceX supplied relay box was used to perform independent power switching of 
the AFSS Chassis and the LCT2. It also contained relays to perform power switching between the onboard 
batteries (internal) and the on-ground power supply (external). 

> 2 each 50 Pin Connectors (on standoffs) - The standoff connectors held the power and ground distribution 
busses for the various subsystems and provided access to test points primarily used during bench testing. 

> GPS Splitter - A COTS RF splitter was used to connect a single GPS patch antenna with an integrated LNA to 
both GPS receivers. 

> GPS Switch - A COTS RF switch was used to permit insertion of simulated GPS RF data into the test article 
during end-to-end functional testing conducted during test-article build up and integration with the vehicle. The 
switch was not used during countdown or launch operations. 

> LCT2 Splitter - A COTS RF splitter was used to direct the S-band telemetry data from the LCT2 to two patch 
antennas mounted on the vehicle skin. 

> Interface Connectors - All off-deck I/O and power signals were routed through the interface connectors. These 
included EGSE controlled signals, power, and an interface with the SpaceX Falcon 1 telemetry system. 

C. TA3 

A third test article is currently being built for a planned sounding rocket launch in Fall 2008 from Wallops 

Island, VA. TA3 addresses various lessons learned from Demo 2 and makes several steps toward the final design 

goal of a unit meeting all requirements as a flight termination system. 
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AFSS TEST ARTICLE 3 (PRELIMINARY) 

APPROXIMATE WEIGHT: 90 - 100 LBS 
CG FROM AFT JOINT: 16.5 INCHES 
IROLL: .88 SLUG-FT 2 
IPITCH: 1.25 SLUG-FT 2 


Figure 5. TA3 Experiment Section 


Advancements planned for TA3 include: 

V Add a GPS/IMU solution. The AFSS team has written a Kalman Filter to integrate a Javad 100 GPS 
receiver and a Floneywell FIG 1700 inertial measurement unit. Testing has been performed on an F-104 
aircraft. 

•S The Radstone flight processor used on TA3 required a great deal of work to overcome its sensitivity to high 
vibration levels. It was flown with shock dampeners. The backplane is being redesigned, the GPS/IMU 
implementation is being incorporated and communications between processors are being improved. 

•S Software upgrades will include additional coding. Safing commands will be included and pre-launch test 
code has been upgraded. 

•S A simulated FTS circuit will simulate actual voltage and current requirements. 

•S The ground support equipment will have a modified graphical user interface to relieve operators from 
manual commands. 

•S AFSS will be commanded from the ground in and out of an inactive mode to demonstrate ability to hand 
over control to conventional human-in-the-loop ground based systems. 

VII. Auxiliary Development 

In addition to hardware and software, several auxiliary developments will be required to support an autonomous 
system. These developments are also underway at NASA. 

V Mission Configuration Tool: Autonomous action does not eliminate the need for human involvement. It 
places emphasis on the mission planning. A graphical tool is required to assist range safety officers in 
configuring mission rules. 

V Hardware-in-the-Loop (HWIL) simulation facility: During development, it will be necessary to do 
extensive testing to validate both software and hardware. Wallops Flight Facility possesses a state of the 
art GPS and IMU simulation facility which can test mission rules against nominal and non-nominal 
trajectories. It is currently being upgraded to allow unattended Monte Carlo variation of trajectory and 
performance patterns. It is envisioned that such a tool will be required to validate programming before 
launches. 

V GSFC IV&V: Internal validation and verification is currently being performed by the Goddard Wallops 
Real Time Flight Software Group in order to prepare for submission to formal NASA IV&V. 
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S GSFCAVFF Range Safety Certification Study: Although the specifications for autonomous flight 
termination systems have been defined in RCC 319, the tailoring process has never been performed and no 
autonomous system has been used on a range in the United States. The NASA Wallops Research Range 
has agreed to participate in a tailoring of RCC 319 with a goal of certifying its use. It is hoped that this 
pathfinder exercise will aid in a general acceptance at other ranges. 

■f Technology transfer initiation: NASA’s interest in AFSS is purely in research and development and 
making available a system that can greatly reduce the cost of access to space. Two more developmental 
flights are planned and the team would consider briefly filling a gap for hypersonic vehicles which 
absolutely require it. However, a speedy transition to a commercial manufacturer of the units is planned. 

VIII. Summary 

NASA has engaged in a multi-year, multi-center development process to establish a baseline architecture, a 
concept of operations, and a detailed design for implementing an Autonomous Flight Safety System that achieves 
compliance to fundamental requirements established by the range safety community. 

Two successful prototype demonstrations of the technology have been completed and a third is expected in the 
spring of 2009. NASA is now proceeding toward setting up the mechanisms for technology transfer of a working 
system. 

NASA desires continued flight test opportunities to further demonstrate the viability of the systems to users and 
the range safety community. It is felt that this technology will play a crucial role in the ORS vision of truly 
responsive space access while maintaining public safety. 
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